Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@googlebot I signed it!

Hi @amithanda — just checking in on this one. Is there anything blocking review, or would adding the "TC review" label help get it into the queue? Happy to address any feedback.

Reviewing as co-author of the related Ideas discussion [#298](#298) (dev.ucp.shopping.eligibility) and independent implementer — UCPReady (WooCommerce) has built this verification flow in production.

The wire format here is consistent with what we designed in #298. A few observations from the implementation side:

Strong alignment with #298:

• The provider_jwks + kid + sig pattern matches the JWKS verification flow we implemented — fetch once, cache 24h, verify offline. No callback to the provider at validation time is the correct design.
• expires_at outside payload is the right call — it allows the business to enforce time bounds without breaking the provider's signature over payload. We handle this identically in UCPReady's JWT validation.
• The sibling map pattern (attestations keyed by reverse-domain eligibility claim) is cleaner than what we initially sketched in Proposal: `dev.ucp.shopping.eligibility` — Machine-Readable Product Preconditions for Agent Commerce #298 — it allows multiple claims with different providers in a single checkout, which answers open question Welcome to Universal Commerce Protocol (UCP) Discussions! #3 from our proposal.

One implementation note:
The spec says "platforms must preserve the provider's original serialization" for sig verification to work end-to-end. This is critical and easy to get wrong — any JSON re-serialization between the attestation provider and the business will break the signature. Worth adding an explicit note in the schema or docs that payload must be treated as an opaque object and passed through without transformation or key reordering. Implementers who deserialize and re-serialize JSON (which most do) will hit this silently.

On expires_at format:
The example uses ISO 8601 (2026-03-13T19:50:32.530Z). Worth confirming this is RFC 3339 with UTC offset required (consistent with the rest of the UCP spec), not just ISO 8601 broadly.

Overall this PR is well-structured and the approach is sound. The payload serialization note is the main thing worth clarifying before merge.

Thanks for the review, and for linking this to #298 — the two proposals are designed to work together.

On your two points:

Payload serialization: The schema does include this — the payload description reads: "Platforms MUST preserve the provider's original serialization to ensure signature verification succeeds." But you're right that it's easy to miss buried in a field description. Worth surfacing more prominently — happy to add a dedicated implementation note in the PR description or a top-level description in the schema if the TC prefers.

expires_at format: The schema uses "format": "date-time", which in JSON Schema is RFC 3339 (section 5.6) — consistent with checkout.json which uses the same format. The PR description example doesn't call this out explicitly though, so the ambiguity is fair. Can add "RFC 3339" to the expires_at description to match the convention in checkout.json.

Appreciate the implementation-side validation — having an independent implementer confirm the wire format aligns with a production system is exactly the kind of feedback the TC looks for.